-
Notifications
You must be signed in to change notification settings - Fork 415
Make channel_type required #3896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
👋 Thanks for assigning @joostjager as a reviewer! |
🔔 1st Reminder Hey @joostjager! This PR has been waiting for your review. |
fuzz/src/full_stack.rs
Outdated
@@ -1067,7 +1067,7 @@ fn two_peer_forwarding_seed() -> Vec<u8> { | |||
// inbound read from peer id 0 of len 32 | |||
ext_from_hex("030020", &mut test); | |||
// init message (type 16) with static_remotekey required, no channel_type/anchors/taproot, and other bits optional and mac | |||
ext_from_hex("0010 00021aaa 0008aaa208aa2a0a9aaa 03000000000000000000000000000000", &mut test); | |||
ext_from_hex("0010 00021aaa 0008aaa218aa2a0a9aaa 03000000000000000000000000000000", &mut test); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume these changes are correct, because test_no_existing_test_breakage
still passes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks in large part to chatgpt:
The change is in the feature bits field: aaa208aa2a0a9aaa → aaa218aa2a0a9aaa
- Each two chars are the hex representation of a byte of feature info
- Each byte contains 8 bits used to mark our features
- This is just a vector, and the LSB is zero, next most significant is
one etc.
aa = bits 56-63
a2 = bits 48-55
18 = bits 40-47
aa = bits 32-39
2a = bits 24-31
0a = bits 16-23
9a = bits 8-15
aa = bits 0-7
Bits 40-47 changed from 08 to 18: 00001000 → 00011000, turning on required bit 44
I think that we can change the hex to 10
(00010000) so that we're only setting the required feature and not the optional one anymore? Admittedly have not read the full fuzz test though, so may be wrong here.
Update: testing suggested diff here - if this passes I think we should only set required, as that's what we're doing irl.
Update: fuzz tests pass with just the required bit, so IMO we should change them!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice @carlaKC taking the extra step with this analysis. Makes sense to match IRL behavior, even though we can of course still receive an init message that contains both optional and required bits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do see in the diff that previously the features
aaa208aa2a0a9aaa
and
aaa20aaa2a0a9aaa
were used, which are now both mapped to the suggested one. Chatgpt says the diff is in data_loss_protect
.
Probably alright, but posting this anyway here.
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
few minor comments, looking good!
fuzz/src/full_stack.rs
Outdated
@@ -1067,7 +1067,7 @@ fn two_peer_forwarding_seed() -> Vec<u8> { | |||
// inbound read from peer id 0 of len 32 | |||
ext_from_hex("030020", &mut test); | |||
// init message (type 16) with static_remotekey required, no channel_type/anchors/taproot, and other bits optional and mac | |||
ext_from_hex("0010 00021aaa 0008aaa208aa2a0a9aaa 03000000000000000000000000000000", &mut test); | |||
ext_from_hex("0010 00021aaa 0008aaa218aa2a0a9aaa 03000000000000000000000000000000", &mut test); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks in large part to chatgpt:
The change is in the feature bits field: aaa208aa2a0a9aaa → aaa218aa2a0a9aaa
- Each two chars are the hex representation of a byte of feature info
- Each byte contains 8 bits used to mark our features
- This is just a vector, and the LSB is zero, next most significant is
one etc.
aa = bits 56-63
a2 = bits 48-55
18 = bits 40-47
aa = bits 32-39
2a = bits 24-31
0a = bits 16-23
9a = bits 8-15
aa = bits 0-7
Bits 40-47 changed from 08 to 18: 00001000 → 00011000, turning on required bit 44
I think that we can change the hex to 10
(00010000) so that we're only setting the required feature and not the optional one anymore? Admittedly have not read the full fuzz test though, so may be wrong here.
Update: testing suggested diff here - if this passes I think we should only set required, as that's what we're doing irl.
Update: fuzz tests pass with just the required bit, so IMO we should change them!
fuzz/src/full_stack.rs
Outdated
@@ -1168,7 +1168,7 @@ fn two_peer_forwarding_seed() -> Vec<u8> { | |||
// inbound read from peer id 1 of len 32 | |||
ext_from_hex("030120", &mut test); | |||
// init message (type 16) with static_remotekey required, no channel_type/anchors/taproot, and other bits optional and mac | |||
ext_from_hex("0010 00021aaa 0008aaa208aa2a0a9aaa 01000000000000000000000000000000", &mut test); | |||
ext_from_hex("0010 00021aaa 0008aaa218aa2a0a9aaa 01000000000000000000000000000000", &mut test); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitnit: comments here say that init has no channel_type
?
(pre-existingly wrong, but let's update here)
pushed changes addressing comments diff |
Diff lgtm, only remaining items for me:
Outdated: |
8f9289d
to
b525e38
Compare
🔔 1st Reminder Hey @carlaKC! This PR has been waiting for your review. |
🔔 2nd Reminder Hey @carlaKC! This PR has been waiting for your review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, ready for a squash 👍
} | ||
|
||
#[test] | ||
fn test_rejects_if_channel_type_differ() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, thx for adding 👍
|
||
open_channel_msg.common_fields.channel_type = | ||
Some(channel_a.funding.get_channel_type().clone()); | ||
let mut channel_b = InboundV1Channel::<&TestKeysInterface>::new( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-blocking/for a follow up: these tests could benefit from being DRY-ed up a bit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree that it would have been nice to do it with a parameterized test, to easily go through the variants.
Re-ran the fuzz failure to see if that would help (no space on device is usually a GH issue), but no avail. Also on master so don't think it's blocking here. |
Set the option_channel_type feature as required and fail the channel if channel_type is not included during channel negotiation in open_channel or accept_channel.
b525e38
to
7313d10
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I think we can wait for the fuzz to pass as this PR isn't very conflict sensitive?
Closes #3872
Changes:
option_channel_type
feature as required.channel_type
is not included during channel negotiation.